After completing this lesson, you’ll be able to:
The provincial government has given the city a grant to fund new public art in parks.
A colleague has created a workspace to analyze the amount of art in each city park, and we are carrying out a code review to ensure that the workspace is efficient and well-designed.
Start FME Workbench (2024.1 or later) and open the starting workspace.
Reading from the web can introduce variability that makes it difficult to accurately assess workspace performance. Therefore, this workspace uses local paths to C:\FMEData. If you do not have FMEData on your machine, you can download the source data (linked in the Resources section above) and point the workspace to use the local files.
Your colleague ran the workspace with caching turned on and informed you it took about twenty seconds to run. Try running it yourself with feature caching enabled and the default parameters. Note the total runtime. It should look something like this:
2024-03-06 11:57:01| 14.5| 0.0|INFORM|Translation was SUCCESSFUL with 11 warning(s) (70 feature(s) output) 2024-03-06 11:57:01| 14.5| 0.0|INFORM|FME Session Duration: 47.3 seconds. (CPU: 6.6s user, 7.9s system) 2024-03-06 11:57:01| 14.5| 0.0|INFORM|END - ProcessID: 138924, peak process memory usage: 647444 kB, current process memory usage: 161712 kB
Now - to test production performance - turn off feature caching. There are no Inspector or Logger transformers, and no parts are disabled. Re-run the workspace.
You should find that the workspace runs a lot more quickly this time - perhaps in as little as twenty seconds:
2024-03-06 11:53:44| 6.6| 0.0|INFORM|Translation was SUCCESSFUL with 4 warning(s) (70 feature(s) output) 2024-03-06 11:53:44| 6.6| 0.0|INFORM|FME Session Duration: 21.3 seconds. (CPU: 3.0s user, 1.5s system) 2024-03-06 11:53:44| 6.6| 0.0|INFORM|END - ProcessID: 150772, peak process memory usage: 499056 kB, current process memory usage: 155572 kB
This clearly shows the performance reduction that caching can cause. In these examples, it runs without caching, resulting in a 54% decrease in total runtime. This is particularly true in a workspace processing large raster datasets. Caching shouldn't be required in a production workspace because the authoring and debugging phases of development should be complete.
Although the workspace now runs very quickly, we could assess the relative performance of each section anyway.
Firstly, disable all components after the readers and run the workspace. Make a note of the time the workspace now takes to run (still without caching):
2024-03-06 12:08:27| 4.3| 0.0|INFORM|Translation was SUCCESSFUL with 3 warning(s) (0 feature(s) output) 2024-03-06 12:08:27| 4.3| 0.0|INFORM|FME Session Duration: 19.8 seconds. (CPU: 0.7s user, 0.2s system) 2024-03-06 12:08:27| 4.3| 0.0|INFORM|END - ProcessID: 68880, peak process memory usage: 150104 kB, current process memory usage: 128460 kB
Now enable all transformers, leaving only the writers disabled. Re-run the workspace and make a note of the performance:
2024-03-06 12:11:23| 4.5| 0.0|INFORM|Translation was SUCCESSFUL with 4 warning(s) (0 feature(s) output) 2024-03-06 12:11:23| 4.5| 0.0|INFORM|FME Session Duration: 33.6 seconds. (CPU: 1.8s user, 2.7s system) 2024-03-06 12:11:23| 4.5| 0.0|INFORM|END - ProcessID: 11320, peak process memory usage: 186568 kB, current process memory usage: 154104 kB
From this, we can calculate the length of each stage of the workspace:
Do these calculations; you'll need the answers for the quiz.
This course has illustrated basic techniques for designing with performance in mind. To learn more, check out the Optimize Workspace Performance course.
